With the explosive growth of the Internet and the World Wide Web, an ever-increasing number of computers of disparate platforms are being connected together. Often, companies employ an Internet-based network operating within the company or world wide, for assisting with its data processing needs. In such an environment, clients (i.e., end-user's work stations) typically operate Web browser software (e.g., Microsoft Internet Explorer or Netscape Navigator) connected to a Web server, often operating in conjunction with a back-end data server. A Web browser communicates with Web servers using Hypertext Transfer Protocol (HTTP), a simple request/response protocol for information transfer using TCP/IP. The Web server receives a request, retrieves the requested object (e.g., file), sends it to the browser, and then drops the connection.
In typical operation, end-users operate various client applications at the client machines which, in turn, connect to the servers for obtaining corporate data--a form of distributed computing. Such an arrangement is problematic, however. One problem, for instance, is tracking the applications themselves. Since the applications run or operate at client machines, a company may need to track and manage a multitude of client applications. Each client application, in turn, can itself be comprised of multiple versions which can be updated independently. A core problem, therefore, is managing different versions of applications, each of which can be updated independently.
A change to any one application has a rippling effect, as such a change must be propagated to each client dependent on that application. As a client application is executing, the system should ensure that that client obtains the latest version of the application (or of independently updated components). Other problems include (1) too many individual applications to keep track of--both for users and for IS administrators; (2) too difficult to keep track of what versions of each application exists; (3) very expensive to keep everyone's desktops up-to-date (incurring costs even if the user never access the program); and (4) too difficult to distribute apps to remote sites.
The classic approach to this problem--creating a monolithic "mega-application" that contains all possible features--is, in itself, problematic. For example, resource needs of these applications drive increasing hardware requirements and accelerate hardware turnover. Further, as new functionality is added to the application, the entire application must be reinstalled on all the clients, incurring re-installation costs.
At the same time in such an environment, however, the client-side application represents only a portion of the operating environment. For instance, business logic for such a system can be separated out from client applications and, instead, be implemented at the server side, thereby providing a central repository for business logic. To a certain extent, an HTTP server is a facilitator of such an approach, generally facilitating the interaction of a client-side web browses with backend data stored on a server.
Additionally, HTTP servers facilitate the integration of client-side web application with the Internet. For example, a user browsing web pages can, in a transparent manner, launch local applications which display Web-downloaded documents, by simply clicking on a link to the corresponding application. Although this approach provides a scheme for supporting widely-installed applications, the approach is not designed for nor particularly well suited to distributing applications within a company (or larger organization).
A newer approach to providing distributed application functionality is Microsoft's ActiveX technology (ActiveX SDK available at http//www.microsoft.com/msdownload/activex.htm; the disclosure of which is hereby incorporated by reference), which includes "ActiveX Controls" and "Active Document." An ActiveX Control in implemented as a rectangular control appearing within an Hypertext Markup Language (HTML) page, a well-known format. When the page is loaded into a browser, the browser automatically downloads the control and runs it. The approach has its disadvantages, however. First, the ActiveX Control must exist within a container--an HTML page--and, thus, must operate within the confines of that container. For instance, the control does not have access to the entire screen region for the page (as it must exist as a containee within the page). Further, since the ActiveX Control relies on an HTML page as the "downloader" container, the control can only be inserted into HTML pages; it cannot be deployed within other containers or standalone. Since it is forced to be a client of HTML page, an ActiveX Control has an inherent limit in its deployment.
Consider, for instance, an application constructed so that separate modules or components of the application are downloaded over a period of time, as an end-user envokes different functionality. Accordingly, greater flexibility is needed for the underlying framework of the application--flexibility which is not provided by the approach of employing an ActiveX Control embedded within an HTML page. All told, since an ActiveX component is designed to serve as a component, it does not provide and adequate framework for an entire application.
Another approach is to employ a control which serves as a stub for launching another application, one which executes within its own window. Since the approach does not provide seamless integration with the browser, it is undesirable. For instance, if the user selects the "back" button from the browser, what treatment, if any, should the separately executing window receive. Therefore the approach of launching a separate process sacrifices the seamless integration which users have become accustomed to when using web browsers. Both ActiveX Controls and Java applets suffer from this problem.
An ActiveX "Active Document" solves this user interface problem, yet itself creates other problems. Specifically, an active document does not include the ability to download program code. In particular, an active document (e.g., Microsoft Word Document) requires that a host application (e.g., Microsoft Word) be present locally on the users machine. Specifically, the HTML page includes a reference indicating thatthe document (data file) can be viewed by launching a session of the locally-stored hosting application.
From the perspective of attempting to solve the business problem of distributing applications with the latest version downloaded automatically, such an approach is unacceptable. Specifically, the program code (for the application) is stored locally at the users machine with no provision for downloading program code at the time of the programs execution. Although an active document allows one to have a downloadable "document" (logical representation of the uses data, such as the text in a word processing file), it does not provide a downloadable "view" (i.e., the code that creates the on-screen representation of that data).
The World Wide Web as it exists today is a distributed, interconnected set of documents that are available from anywhere. What is really needed is a system which provides a facility for achieving the same sort of distribution and interconnections between application objects. Such a system would provide a centralized repository for program code (e.g., stored on a server), with the ability to keep the code up to date, together with seamless integration into the Worldwide Web so that users can easily access distributed applications through Web page links. The present invention fulfills this and other needs.